Offline: I discussed with @sunshowers that, although I nudged us down this path, the complexity added here (both in terms of what the reader/author of the manifest has to deal with and the implementation) seems way more than I would have expected. I think it goes something like this:

• We're trying to use filter rules to notate that certain edges are intra-deployment-unit only.
• Prior to this PR, it is not allowed for a particular dependency path to match more than one filter rule, and none of them does. This is not strictly required but it was a choice I made early on to keep the system understandable and debuggable. (This avoids needing rules to define what happens when multiple rules match, having to understand how these rules fit together to achieve the author's intent, and needing to build tooling to dump out what's going on when a human is inevitably confused by what the tool did.)
• However, the way rules are defined today, there necessarily is some overlap between this new kind of rule and some existing rules. The case we uncovered today was dpd:

dap@ivanova dendrite $ cargo tree -i gateway-client -p dpd
gateway-client v0.1.0 (https://github.com/oxidecomputer/omicron?branch=main#8e30605f)
├── dpd v0.2.0 (/home/dap/dendrite/dpd)
└── nexus-types v0.1.0 (https://github.com/oxidecomputer/omicron?branch=main#8e30605f)
    └── nexus-client v0.1.0 (https://github.com/oxidecomputer/omicron?branch=main#8e30605f)
        ├── dpd v0.2.0 (/home/dap/dendrite/dpd)
        └── oximeter-producer v0.1.0 (https://github.com/oxidecomputer/omicron?branch=main#8e30605f)
            └── dpd v0.2.0 (/home/dap/dendrite/dpd)

There are three paths here from dpd (the server component) to gateway-client (the client). The direct dependency dpd -> gateway_client is legitimate and needs to be marked intra-deployment-unit-only. The other two paths here are bogus and there's a rule marking them as such (any path through nexus-client to gateway-client gets marked bogus). However, there's no obvious way in metadata to discriminate between the legitimate path and the other two: all have the ancestor (or server) dpd and client gateway-client. So implementing this behavior with the existing filter rules requires relaxing the constraint that a path never match two rules.

That's okay, but how would we relax it? This PR essentially says: with this new kind of rule, we divide filter rules into two groups: those using ancestor and those using server. A path may match at most one of each group of rules. There's some non-obvious behavior in evaluating the filter to make this work and that's where lies a lot of the complexity that makes me uncomfortable:

• there are now two categories of rules, separately from (but not orthogonal to) the evaluation
• paths are now allowed to match multiple rules, with some non-obvious logic about when that's allowed and what happens when that happens.
• there are now two types that logically represent the same thing, which is how we evaluate a particular API dependency (Evaluation/DependencyEvaluation)
• what used to be a simple match is now a function call to the new type
• there are now two types for RawDependencyFilterRule/DependencyFilterRule (this might be fine, but just noting it currently only exists to validate the two categories of rule)
• should_include now takes both the server and the dep_path

One alternative I considered is to resolve this problem a different way: say that paths can match more than one rule only if all but one are bogus, and in that case, the bogus matches are ignored. This may be plausible, but as I went to prototype it, I realized that even adding an evaluation like intra-deployment-unit is a little goofy because of the way it overlaps with the existing dag evaluation. That is, the docs I was going to write would say "this is like dag, but also implies ...". Maybe instead we could make this a new property of the rule that only applies to dag rules? But anyway, all of this has made me feel like we're better off for now going back to 5e04994 (not treating these as filter rules, but as separate metadata that happens to look pretty similar). Sorry for the wild goose chase. I'll try to take a swing at this.

Okay, I've implemented the proposed code changes, along with pulling in some improvements @sunshowers made before I wound back. From my perspective what's left here is reviewing the specific metadata. I'll take a look at that tomorrow.